fix(compilers/openapi): stop silently dropping operation details - #272

Summary

Six places in the operation, parameter and content lowering were reported as dropping declared
source content with no IR representation and no diagnostic. I reproduced each one against the
current tree before touching anything — compiling a minimal spec and reading both the emitted IR
and the complete diagnostic list — because the report predates the compiler split and several
losslessness fixes have landed since.

The five that still reproduced share one mechanism: declared content that reaches the IR in no form
at all and says nothing about it. Each is now either lowered, kept verbatim under Unmodeled with
ReasonNoIRHome and a degraded-construct diagnostic, or — for the one case where keeping it as
declared is the right answer — reported under a diagnostic code of its own.

1. Header style and explode. explode decides whether a collection-valued header goes on
the wire as one repeated field or one comma-joined value, so losing it left the IR unable to say
how the header serializes. ir.Property has a field for neither (ir.PartEncoding does, but that
is a multipart part's own config), so both are kept verbatim, the same way a parameter schema's
xml hints already are. This fixes both callers of the shared header lowering — response headers
and a multipart part's per-encoding headers — rather than only the response position it was noticed
at.

2. Path-item servers on every route. A path item is one object with three parents. The
existing applyPathServers is now called from the webhook walk and the callback walk as well as
from paths, so a delivery-host override written on a webhook or a callback is kept and reported
exactly as the same declaration under paths already was. No second helper was written.

2b. An operation's own servers, which override the path item's. OpenAPI lets both a Path
Item Object and an Operation Object declare servers and says the operation's override the path
item's. Only the path item's were read, so a document declaring both kept the superseded list
under openapi:servers and dropped the effective one outright: an emitter reading that entry would
route to a host the operation had replaced, and nothing reported it either way. Fixing item 2 alone
would have propagated that to two further routes.

The two are kept under separate keys — the operation's own under openapi:operationServers —
because they are two declarations at two pointers, and one map key cannot hold both without the
surviving list depending on which lowering ran last, silently. The path item's keeps the key it
already ships under, so no golden changes meaning. Preservation happens in lowerOperation rather
than at each route, so no route added later can forget it, which is exactly how the path-item half
came to be missing on two of its three.

3. allowEmptyValue. Its neighbours — style, explode, allowReserved, the content-style
media type — all reach ir.HTTPParamBinding; this one has no field there and no reader anywhere.
It is kept on ir.Parameter, the carrier at this position that has an Unmodeled map at all.
Preservation keys off presence rather than truth: allowEmptyValue: false is a declared fact too,
and recording only the true spelling would be the compiler deciding which declarations count.

4. Reserved headers — an explicit, documented policy, at every position that states it.
OpenAPI says a reserved header declaration SHALL be ignored in three places, not one: a parameter
with in: header named Accept, Content-Type or Authorization (§4.8.12); a Content-Type
entry in a response's headers map (§4.8.17), whose media type the response's own content map
already names; and a Content-Type entry in an encoding's headers map (§4.8.15), which the
encoding's own contentType describes separately. The compiler now keeps lowering all three and
reports each under one new stable code, openapi/reserved-header-name, at warning severity.

Keeping the declaration is the deliberate choice: dropping declared content is a loss, and whether
to generate a header that collides with the security scheme, with content negotiation, or with the
media type the position already owns is an emitter's decision, not a compiler's. What was wrong was
making that deviation invisible — an emitter had no way to tell such a declaration from any other.
The comparison is case-insensitive, since HTTP field names are. The rationale is recorded on the
diagnostic code itself, which is where the next reader will reach it.

The two headers-map positions report at the map entry's own pointer rather than the header object's,
because the reserved thing is the key a header is mapped under: one component $ref'd from a
reserved key and from an ordinary one is two declarations, and only the reserved key is reported.
That is the opposite choice from the style/explode preservation above, which keeps keywords the
header object itself writes and so records them at the declaration.

The report is unconditional rather than an Options switch, and that too is recorded on the code.
Invariant 6 sends anything inferred to injectable policy, and nothing here is inferred: the names
are fixed by the specification, the comparison is against a declared name, and the lowered document
is identical whether or not the diagnostic fires — removing the call reddens only the diagnostic
assertions, no golden and no conformance IR. Warning rather than error because the document is
well-formed, and because harness.Check returns at the first error diagnostic, which would hide
every later finding in the same spec.

5. Error-response content, whatever its arity. ir.ErrorCase holds a single TypeRef and no
media type, so an error declared only as application/problem+json reached the IR indistinguishable
from one declared as application/json. One entry losing the key it was written under is the same
loss as several losing all but the first, so the content map is now kept in both cases, with the
diagnostic naming which of the two happened rather than one message covering both.

docs/ir-design.md's OpenAPI mapping row is updated for each of these, since it is normative about
where a construct lands.

Scope

Nothing from the report was left out. Item 6 needed no change and is recorded above with the
evidence rather than quietly omitted. None of the five fixes mints an IR node, so no new ID
namespace is involved; the two-order oracle in internal/harness sweeps the whole conformance
corpus and stays green over the extended fixtures.

Probing turned up four further drops in the same walk that are not part of this change:

• openapi: response extensions dropped everywhere, links dropped on error responses #275 — a Response Object's x-* extensions are read at no response at all, and links survives
  on a success response but not on an error one.
• openapi: encoding allowReserved and extensions are dropped silently #291 — an Encoding Object's allowReserved and x-* reach no IR field, no Unmodeled entry and
  no diagnostic. Same mechanism as item 3 at a different object; kept out because the extensions
  half overlaps openapi: response extensions dropped everywhere, links dropped on error responses #275 and the two should be settled together.
• openapi: path-item summary and description reach the IR nowhere #292 — a Path Item Object's summary and description are read nowhere. Held back deliberately:
  there is no ir.PathItem, so it needs a recorded decision between merging into each operation's
  Docs and preserving raw, and that is a lowering choice rather than the preservation this PR
  makes.

Each is a separate rule from anything here, so each gets its own change rather than riding along.

Test plan

Fixtures were extended in the conformance corpus rather than added beside it, since none of these is
a new capability row: header-content-schema gains a collection header declaring style/explode,
webhooks and callbacks each gain a path-item servers override with a distinct URL,
param-styles gains an allowEmptyValue parameter, and per-status-errors already carried a
single-media error response. Unit tests in the operation package pin the pointers and diagnostic
messages the goldens only record. unwitnessed.golden.txt shrinks by one line: ErrorCase.Unmodeled
had no witness in the corpus before this.

webhooks additionally declares an operation-level servers override beside its path-item one, so
the corpus witnesses both keys of that pair and the two-order oracle, irverify and the JSON round
trip all reach the case where they could collide.

The reserved-header rule is unit-tested rather than added to the corpus, since it changes only the
diagnostic stream: the header lowers identically either way, so a fixture would move a golden
without witnessing the report. Both lowerHeaders callers are covered, and the two-keys-one-
component case pins which pointer the report lands on.

Every new behavioural assertion was checked by planting the defect back and watching it go red:

Full gate, in order: gofmt -l clean, go vet ./... clean, golangci-lint run 0 issues,
go build ./... clean, ./scripts/check-coverage.sh passes at 100% of statements.
go run ./cmd/morphic-harness over both testdata/conformance/openapi and testdata/golden/openapi
reports ok for every spec, which is what exercises the two-order diff, irverify and the JSON
round-trip over the extended fixtures.

Closes #39.